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Present Invention 

The present application relates to techniques for controlling access to records stored in a 
database. As a representative claim, claim 1 1 pertains to a method for controlling access to 
records stored in a database. Claim 1 1 recites defining a calculation expression for a password 
associated with one or more users of a database. The calculation expression is defined based on 
at least one field of data used in a plurality of records stored in the database. It should be noted 
that the field of data is a variable which may have different values for each of the plurality of 
records. It should also be noted that the calculation expression can be evaluated at least partly 
based on the at least one field of data used in the plurality or records, thereby allowing access to 
each individual record to be selectively controlled based on the value of the field of data stored 
for each of the records of the database (Claim 11). 

Figure 7 of the present application depicts an interface for specifying a calculation 
expression 602, namely: 

"Billing State = CA" 

Referring now to Figure 8, the calculation expression can be evaluated for the records 
"ACC001, ACC002, ACC003 and ACC004" based on the field "Billing State" to effectively 
allow access to the records that have their "Billing State" equal to "CA." For example, access to 
the record "ACC001" can be granted while access to record "ACC003" can be denied when the 
calculation expression 602 is evaluated. 
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Rejection of claims under 35 U.S.C. §103(a) 

The Examiner's rejection of claims 11-15, 38-42 and 51-52 under § 103(a) is primarily 
based on a Granted Permission Table shown in Fig. 15A of Bapat et al. which is reproduced 
below. 

Granted Permissions Table for Table 1 



1502 



1510 



User Name 


Object Name 


Operation Type 


user_x 


object_xyz 


SELECT 


user_x 


object_qrs 


UPDATE 


user_y 


object_xyz 


SELECT 


user_y 


object_abc 


DELETE 


user_z 


object_def 


SELECT 


group_a 


object_hij 


SELECT 


group_z 


object J kl 


SELECT 



Clearly, Bapat et al. teaches a Granted Permission Table . It is also abundantly clear that 
a table does NOT teach or even remotely suggest a calculation expression which can be 
expressed based on at least one database variable and subsequently evaluated for records of 
database based on actual values stored for the variable(s) associated with each record. Those 
skilled in the art readily appreciate the advantages that a calculation expression provides over a 
table. One advantage is that there is no need to construct a table that would have to cover every 
case and then perform a lookup procedure to find the appropriate entry. This means that less 
storage and/or effort may be needed since a calculation expression can be defined and evaluated 
when needed (e.g., dynamically at runtime) to determine whether access to a record should be 
granted. Furthermore, a calculation expression provides an extremely powerful tool that can be 
used to define extremely complex expressions that could not be provided statically in a table. By 
way of example, a calculation expression can be defined on state variable of a database (e.g., 
current time, last time accessed, last person accessed) (see, for example, claim 14). Given that 
the Examiner's rejection is essentially based on a permission table, it is very respectfully 
submitted that the Examiner's rejection is clearly improper and should be withdrawn as Bapat et 
al. does not teach defining calculation expression. 

Moreover, it is respectfully submitted that Bapat et al. cannot possibly teach or even 
remotely suggest several additional features of claim 14. Contrary to the Examiner's assertion, it 
is respectfully submitted that checking the Granted Permission Table "to see if user has specific 
granted items" does NOT teach " evaluating a calculation expression ." It should be apparent that 
the methodology of Bapat et al. could not be further apart from the innovative techniques of the 
invention which allows controlling access to database records based on evaluating a calculation 
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expression. As such, it should be apparent that Bapat et al. cannot possibly teach or suggest: "(a) 
determining at least one value for said at least one field of data stored for a first record of said 
plurality of records, (b) using said at least one value as input to said calculation expression to 
evaluate said calculation expression for said first record, and (c) determining a first result for said 
calculation expression based on said evaluation of said calculation expression for said first 
record, wherein said first result effectively indicates whether to grant access to said first record" 
(claim 11). 

The Examiner has noted that Bapat et al. does NOT teach "identifying a password that is 
associated with one or more user of said database" (Final Office Action, page 15). However, the 
Examiner has asserted that Elmasri teaches "identifying a password that is associated with one or 
more users of said database." Initially, it is respectfully submitted that the Examiner has failed to 
establish a prima facie case of obviousness for failing to properly address the claimed feature of 
defining a calculation expression for a password associated with one or more users of a database. 
Clearly, the mere assertion that a password can be associated with one or more users does NOT 
address the claimed feature of defining a calculation expression with a password. In order to 
establish a prima facie case of obviousness, the Examiner needs to at least show that the cited art 
teaches defining a calculation expression for a password. It is respectfully submitted that the 
Examiner has failed to establish a prima facie case of obviousness. Moreover, it is respectfully 
submitted that neither Bapat et al. nor Elmasri teach or even suggest associating a calculation 
expression with a password. Accordingly, it is respectfully submitted that claim 14 is patentable 
for this additional reason. 

Furthermore, it is respectfully submitted that the Examiner has failed to show a 
motivation or suggestion for combining the references. Clearly, the mere assertion that "by 
using a password to identify a user as taught by Elmasri, the database system is secured and data 
is protected from misuse and against intruders" does not provide a motivation or suggestion for 
combining the references (Final Office Action, page 15). The prior art must suggest the 
desirability of the claimed invention (MPEP 2143.01). The fact that references can be combined 
is NOT sufficient to establish prima facie obviousness and the fact that the claimed invention 
may be within the capabilities of one of ordinary skill in the art is not sufficient by itself to 
establish prima facie case of obviousness (MPEP 2143.01). 

Independent claims 38 and 43 recite similar features as those recited in claim 1 1 and are 
therefore patentable for at least the same reasons. 

It should be noted that the dependent claims recited additional features that render them 
patentable for additional reasons. For example, claim 14 further recites: "wherein said 
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calculation expression can be evaluated at least partly based on at least one state variable." 
Clearly, the cited art cannot possibly teach or suggest this feature. As another example, claim 13 
recites, "wherein said calculation expression is not explicitly defined for said at least one 
operation but said calculation expression is one that has been defined for another operation 
which has been considered as a related operation to said at least one operation." It is respectfully 
submitted that the cited art cannot possibly teach or suggest this feature as it fails even to teach 
associating a calculation expression with a password or an operation. 

Rejection of claims 11, 38, 43 and 56 under 35 U.S.C. 112, first paragraph 

In the Final Office Action, the Examiner has asserted that "using at least one value as 
input to said calculation expression to evaluate said calculation expression for said record was 
not described in the specification." 

As noted above, Figure 7 of the present application depicts an exemplary calculation 
expression "Billing State=CA." Further, the specification describes in detail how the calculation 
can be evaluated for an exemplary set of records depicted in Figure 8. It is abundantly clear that 
the value of the field "State" is provided as input to the calculation expression in order to 
evaluate the calculation expression. As noted in the specification, "the user will not be granted 
editing privileges to record "ACC003" since the field "State" of this record is not equal to "CA" . 
In this way, a calculation expression can be evaluated with respect to a record to determine 
whether to grant or deny access to each record" (specification, pages 13-14). 

Refection of claims 11, 18 and 43 under 35 U.S.C. 112, second paragraph 

In the Final Office Action, the Examiner has asserted that claims 11,38 and 43 omit the 
essential step of "identifying and evaluating the next record." As an exemplary claim, claim 1 1 
recites: "evaluating said calculation expression for each of said plurality of records." According, 
it is respectfully submitted that no essential step has been omitted as the claim specifically recites 
evaluating each of the records. The additional features of (a) determining at least one value, (b) 
using it as input to the calculation expression for a first record and (c) determining a first result 
for the calculation expression based on the evaluating of the calculation expression are not 
necessary and have been recited primarily for clarification. 

Rejection of claims 11-15, 38-43, 45-47 and 53-58 under 35 U.S.C. §101 

Initially, it is respectfully submitted that this rejection was raised for the first time in the 
Final Office Action. Further, the Applicant has requested the method claims to be amended to "a 
computer-implemented" method which should overcome any possible rejection. The Examiner 
has NOT entered the Amendment After Final. Moreover, the Examiner has not provided any 
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explanation as to why a tangible and useful result is not produced. A computer-implemented 
method, computer readable medium including computer program code, database system 
embodied in a computer readable medium, constitute patentable subject matter under 35 U.S. C. 
§101. 

Rejection of claims 53-58 under 35 U.S.C. §102(e) 

In the Final Office Action, the Examiner has asserted that TABLE I of Osentoski et al. 
teaches defining an expression. TABLE I is reproduced below: 

TABLE I 

Type of Data Protect Cd Access 

Diagnosis H Read 

Diagnosis K Read/Write 

Diagnosis L Read/Write 

Procedure H Read 



Clearly, TABLE I of Osentoski et al. does NOT teach or even remotely suggest: defining 
an expression that can be evaluated for each of a plurality of records in a database (claim 53). 
Furthermore, it is respectfully submitted that Osentoski et al. does NOT teach or even remotely 
suggest: " evaluating said expression for said first record of said plurality of records of said 
database" (claim 53). Instead, Osentoski et al. teaches applying access rules to the records of an 
initial set to obtain a final set of records. Then providing access to records of the final result set 
according to an access profile for the user requesting the records (Osentoski et al., Abstract). 
More particularly, "The final result set is passed back through a security component of record 
access component 19 that uses the requesting user's access profile (Table I) to determine the 
user's access level (i.e., None, Read, Read/Write, Read/Write/Delete) to the records of the final 
result set. In the example of Table IV, only records with protections code (Protect_Cd) H, K, and 
L will be returned to the user, and only the K and L records may be updated by the user." 
(Osentoski et al., Col. 4, lines 16-25). Clearly, using an access profile (TABLE I) to determine a 
user's access level does NOT teach or even remotely suggest: evaluating the expression for a 
record and determining, based on the evaluating whether to grant access to the first record 
(Claim 53). 

Respectfully submitted, 

BEYER WEAVER & THOMAS, LLP 

/RMahboubian/ 
Ramin Mahboubian 
Reg. No. 44,890 

P.O. Box 70250 
Oakland, CA 94612-0250 
(650) 961-8300 
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